home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000039_owner-urn-ietf _Fri Jan 31 08:56:37 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA29676 for urn-ietf-out; Fri, 31 Jan 1997 08:56:37 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA29670 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 08:56:34 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23510  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 08:56:32 -0500
  5. Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) 
  6.           id <21458-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 14:25:40 +0100
  7. Date: Fri, 31 Jan 1997 14:25:39 +0100 (MET)
  8. From: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  9. To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
  10. Cc: URL mailing list <ietf-url@imc.org>, urn-ietf@bunyip.com
  11. Subject: Re: [URN] Re: Relative URLs and URNs
  12. In-Reply-To: <9701301832.aa03874@paris.ics.uci.edu>
  13. Message-Id: <Pine.SUN.3.95q.970131142251.246H-100000@enoshima>
  14. Mime-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. On Thu, 30 Jan 1997, Roy T. Fielding wrote:
  22.  
  23. > > Thus spoke Keith Moore:
  24. > > 
  25. > >> If we disallow unencoded '/' within URNs for now, we can always add 
  26. > >> relative URNs later when we understand them better.
  27. > 
  28. > I couldn't disagree more.
  29. > 
  30. > If '/' is disallowed in URNs, then a conforming parser will reject
  31. > a URN containing '/'.  That means you will never be able to introduce
  32. > relative URNs.  Creating barriers to technology just because it isn't
  33. > understood is a mistake, particularly when the only time '/' is
  34. > meaningful for *any* URI is when it is used as a base for parsing
  35. > relative URIs.
  36. > 
  37. > If you aren't using relative forms, then there is no reason to encode '/'.
  38. > If you are, then you don't want '/' encoded.  There does not exist a
  39. > situation in which it is beneficial to disallow '/' in URNs.
  40.  
  41. There might not be any disagreement. Keith wants '/' disallowed
  42. within actually existing URNs. The parser can (and should, in this
  43. case) be more open. "SHOULD" is the best way to say it (contrary
  44. to my message a few minutes ago, where I didn't see that "SHOULD"
  45. was on puprose).
  46.  
  47. Regards,    Martin.
  48.